Method and apparatus for dynamic web page arrangement

ABSTRACT

A browser renders a page for display according to user habits. When a user interacts with a page associated with a network address, an entry is made in a file that associates the element on the page of the user interaction with the network address. When the page is visited again, the file is checked to see if any entry exists. If an entry exists and the stored user interaction is still relevant for that page, the page is rendered so that the location the user interacted with is provided at the top of the display, or the element is re-arranged, as in the case of a table, or both re-positioning and re-arranging occurs. Such page rendering reduces the need for the user to scroll through the page to view the desired information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This is a divisional of co-pending U.S. patent application Ser. No.09/574,157 filed May 18, 2000, which is herein incorporated byreference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to information systems. More particularly,the invention relates to a browser that renders a page to a displayaccording to prior user activity on that page.

2. Background of the Related Art

Information systems, such as the Internet, provide users with access toa large amount of information. Many users of such systems employ a webbrowser or similar program to find the information they are interestedin. Typically, the user selects, loads, and displays electronicdocuments, such as Hypertext Markup Language (“HTML”) documents,utilizing software called a browser, which is typically stored in memoryin the user's (client) computer. HTML documents displayed by the browsergenerally contain areas that, when selected by a user, cause the browserto load and display other HTML documents, allow the user to enterinformation, or enable other user interaction. A selectable area, suchas a hypertext link, may be textual, graphic, or generally anydesignated area of a displayed HTML document. Hypertext links, forexample, are associated with a network address, such as a UniformResource Locator (“URL”), of a destination HTML document that is loadedand displayed when the link is selected by the user.

One problem with electronic documents, such as HTML documents, is thatthe display type and the page formatting can affect the displayed outputviewable by the user. HTML documents are typically displayed on any of avariety of display devices, such as Cathode Ray Tubes (“CRT's”) orliquid crystal displays. Sometimes an entire HTML page can be displayed,other times the user might have to “scroll” the display, that is, selectthat portion of the page the user wants to view that is not currentlyshown, by providing input from a user input device. For example, an HTMLpage might be loaded so that the top of the page appears at the top ofthe display, with a bottom portion of the page not being shown.

The user can typically manipulate arrow keys, a mouse, scroll wheel orsimilar device to scroll down the page. Sometimes the width or length ofthe HTML page exceeds the display area, and a user might have to scrollacross or down the screen to view the desired information. The need toscroll to the desired viewing area may be compounded when electronicdocuments designed for one type of display, such as a desk-top computerdisplay, are viewed on a smaller display, such as the display of a cellphone, which may have only about 11 lines. Unfortunately, the user inputdevices provided with devices that have small displays are often morecumbersome to use than other scrolling devices, such as track balls or“mice” provided with desk-top systems.

Therefore, there is a need for an apparatus and a method for reducing oreliminating the need to scroll a page.

SUMMARY OF THE INVENTION

In one embodiment of the invention, a computer-readable, signal-bearingmedium containing a program for rendering an electronic document to adisplay is provided. The program, when read and executed by a computer,gets an electronic address associated with the electronic document. Theprogram then evaluates a data structure to determine if a user hasinteracted with the electronic document. The data structure contains atleast an entry for a user interaction field on the electronic document.If the user has interacted with the electronic document, the programdetermines if the user interaction field exists on the electronicdocument. If the user interaction field exists on the electronicdocument, the program renders the electronic document to the display sothat the user interaction field is viewable on the display.

In another embodiment another computer-readable, signal-bearing mediumcontaining a program for rendering an electronic document to a displayis provided. The program, when read and executed by a computer, gets anelectronic address associated with the electronic document. Then theprogram determines if a first data structure includes a first userinteraction type associated with the electronic document or a seconduser interaction type associated with the electronic document. If thefirst data structure includes the first user interaction type, theprogram determines if a first entry for the first user interaction typeis present in a second data structure. If the first entry is not presentin the second data structure, the program determines if a second entryfor the second user interaction type is present in a third datastructure. If the second entry is present, the program determines if auser interaction field associated the second entry exists on theelectronic document. If the user interaction field exists on theelectronic document, the program renders the electronic document to thedisplay so that the user interaction field is viewable on the display.

In another embodiment, a method for rendering a document to be displayedon a networked display device is provided. The method retrieves anelectronic document according to a network address. The method thendetermines if an entry associated with the electronic document exists ina data structure, the entry including a user interaction field. If theentry exists, the method determines if the user interaction fieldappears on the electronic document. If the user interaction fieldappears on the electronic document, the method renders a page to displaythe user interaction field in a viewable area of the networked displaydevice.

In another embodiment, another method for rendering an electronicdocument to be displayed on a networked display device is provided. Themethod retrieves the electronic document according to a network addressand then determines if a first entry associated with the electronicdocument exists in a data structure, the first entry including a firstuser interaction field and a first count. If the first entry exists inthe data structure, the method determines if the first user interactionfield appears on the electronic document. If the first user interactionfield appears on the electronic document, the method moves the firstuser interaction field from a first current location on the electronicdocument to a viewable portion of the display. The method alsodetermines if the data structure includes a second entry associated withthe electronic document, the second entry including a second userinteraction field and a second count. If the second entry exists in thedata structure, the method determines if the second user interactionfield appears on the electronic document. If the second user interactionfield appears on the electronic document, the method moves the seconduser interaction field from a second current location on the page to theviewable portion of the display, wherein the second user interactionfield is displayed above the first user interaction field if the secondcount is greater than the first count.

In another embodiment, a method for storing user interaction habits withan electronic document is provided. The method gets a first userinteraction with the electronic document and a network addressassociated with the page. The method then determines if the first userinteraction is a first user interaction type. If the first userinteraction is the first user interaction type, the method getselectronic document field data associated with the first userinteraction and stores storing the electronic document field dataaccording to the first user interaction type and the network address.The method increments and stores a count associated with the first userinteraction.

In another embodiment, a configurable client computer for use in aclient-server computer system is provided. The client computer includesa display and a browser capable of rendering electronic documents to thedisplay. The browser can access user habit data in association withelectronic document address data. A renderer invoked by the browser isable to render a selected electronic document to the display accordingto the user habit data.

In another embodiment, a configurable client computer for use in aclient-server computer system is provided. The client computer includesa display capable of displaying, at most, a first number of lines and abrowser capable of rendering electronic documents to the display. Thebrowser can access user habit data in association with page addressdata. A renderer evaluates the user habit data in a data file to rendera selected electronic document to the display by rearranging elements onthe selected electronic document according to the user habit data.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 is a simplified block diagram of a client-server computer systemaccording to an embodiment of the present invention.

FIG. 2 a is a simplified flow chart of a portion of a browser accordingto an embodiment of the present invention.

FIG. 2 b is a simplified representation of a page renderer file.

FIG. 3 is a simplified flow chart of a process to store data for userhabits with a page.

FIG. 4 a is a simplified flow chart of a page renderer process usingpage alteration.

FIG. 4 b is a simplified flow chart of a page renderer process usingpage positioning.

FIG. 5 a is a simplified flow chart of an embodiment of a table rendererprocess.

FIG. 5 b is a simplified representation of a data structure of a tablefile entry.

FIG. 6 a is a simplified representation of a table of information andlinks as might be shown on a display of a networked device as a portionof an electronic document.

FIG. 6 b is an exemplary table shown on a display of a networked deviceaccording to the operation of an embodiment of the present invention.

FIG. 6 c is a portion of the exemplary table not displayed on networkeddevice according to the operation of an embodiment of the presentinvention.

FIG. 7 a is a simplified flow chart of an embodiment of a link rendererprocess.

FIG. 7 b is a simplified representation of a data structure of alink-taken file entry.

FIG. 8 a is a simplified flow chart of an embodiment of a data-enteredprocess.

FIG. 8 b is a simplified representation of a data structure of adata-entered file entry.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention relates to adapting a displayed page according touser activity. A page is typically downloaded from a server computer(“server”) to a client computer (“client”). A browser in the clientcomputer renders the page according to information received from theserver. Page information can be sent from the server to the client in avariety of formats, such as HTML, hand-held device markup language(“HDML”), wireless application protocol (“WAP”), or other format. Forsimplicity of discussion, HTML pages will be used for purposes ofillustration only.

As will be described in detail below, aspects of the preferredembodiment pertain to specific method steps implementable on computersystems. In an alternative embodiment, the invention may be implementedas a computer program-product for use with a computer system. Theprograms defining the functions of the preferred embodiment can bedelivered to a computer via a variety of signal-bearing media, whichinclude, but are not limited to, (i) information stored on anon-writable storage medium (e.g., read-only memory (“ROM”) deviceswithin a computer such as a ROM or compact-disk ROM (“CD-ROM”) readableby a CD-ROM drive); (ii) alterable information stored on writablestorage media (e.g., floppy disks within a diskette drive or a hard-diskdrive); or (iii) information conveyed to a computer by a communicationsmedium, such as through a computer or telephone network, includingwireless communications. Such signal-bearing media, when carryingcomputer-readable instructions that direct the functions of the presentinvention, represent alternative embodiments of the present invention.

FIG. 1 depicts a data processing system 100 in which the preferredembodiment may be implemented. In general, the data processing system100 includes a client computer 122 and at least one server computer 124(additional servers 124 a-124 n are shown). The client computer 122 andthe server computer 124 may be components of the same computer system ormay be separate components connected via a network 126, such as theInternet. The network may be a wire or cable directly electronicallycoupling the client to the server, or may include a wirelesstransmission portion, such as are used with cell phones and other“wireless” devices. Accordingly, it is understood that the client mightinclude other components, such as a receiver and modem (i.e., “wirelessmodem”).

The client computer 122 includes a Central Processing Unit (“CPU”) 128connected via a bus 130 to memory 132, storage 134, input device 136 andoutput device 138. The input device 136 can be any device to give inputto the client computer 122. For example, a keyboard, keypad, light pen,touch screen, button, mouse, track ball or speech recognition unit couldbe used. The output device 138 is preferably any conventional displayscreen, such as liquid-crystal displays (“LCDs”) or cathode-ray tubes(“CRTs”) and, although showing separately from the input device 136, theoutput device 138 and input device 136 could be combined. The outputdevice generally includes a viewable portion 139 that a user can readfrom. For example, a display screen with an integrated touch screen, anda display with an integrated keyboard, or a speech recognition unitcombined with a text speech converter could be used.

While memory 132 is shown as a single entity, it should be understoodthat memory 132 may in fact comprise a plurality of modules, and thatthe memory 132 may exist at multiple levels, from high speed registersand caches to lower speed but larger DRAM and SRAM chips. The memory 132contains a browser program 140 that, when executed on the CPU 128,provides support for navigating between the various servers 124, 124a-124 n, for locating addresses at one or more of the servers, forentering date into data fields, and other functions, such as pagerendering. The contents of memory 132 can be loaded from and stored tothe storage 134 as CPU 128 has a need for it.

In one embodiment, storage 134 is non-volatile memory, such asnon-volatile random access memory (“RAM”), flash memory, magnetic memoryor optical storage. In some embodiments, it could be ordinary RAM.Although storage 134 is shown as a single unit, it could be anycombination of fixed and/or removable storage devices, such as fixeddisc drives, floppy disc drives, tape drives, removable memory cards oroptical storage. Memory 132 and storage 134 could be part of one virtualaddress space spanning multiple primary and secondary storage devices.The storage 134 contains various data structures and, as shown in FIG.1, storage 134 contains data files 141 a, 141 b, 141 c (and possiblyothers). The data files store, among other data, user habit informationand are used in rendering a page for display.

In a particular embodiment, a page renderer data file 141 has a datumentry if a particular type of datum or data is contained in other datafiles 141 a, 141 b, 141 c. The other data files store user interactionhabits for various types of user interactions with an electronicdocument. For example, a first data file 141 a could be a tableinteraction file, a second data file 141 b could be a link interactionfile, and a third data file 141 c could be a data entered interactionfile. If a user interaction comprising a table interaction, a linkinteraction, or a data entry interaction occurs, the respective datafile records information about the user interaction with the electronicdocument and provides an entry, i.e., a key, to a data field (see FIG. 2b, reference numeral 224) of the page renderer data file 141. The nexttime the user interacts with the electronic document, the page rendererdata file initiates a page renderer process. Those skilled in the artwill appreciate that these data files and their inter-relation areexemplary only. For example, the key could be generated during anevaluation step of a process (e.g., when a user interaction is evaluatedto determine if it belongs to a type relating to page rendering), orconcurrently with the creation of an entry for the interaction datafile.

Each server computer 124 generally comprises a CPU 142, memory 144, andstorage 146 to one another by a bus 148. It is understood that thisblock diagram is simplified for purposes of illustration, and that theactual server components might be physically separated, and that theserver might include other components, such as displays and inputdevices, which are not shown. The memory 144 includes random accessmemory and/or other writable memory sufficiently large to hold thenecessary programming and data structures that are located on the servercomputer 124 according to a network information address, e.g., a URL.

As shown, the memory 144 includes a hyper-text transfer protocol(“HTTP”) server process 145 adapted to service requests from the clientcomputer 122 regarding HTML documents, which can be called from storageand/or memory, and example of which is the electronic document 147 inmemory 144. The HTTP server process 145 is merely illustrative and otherprotocols known and unknown in the art are contemplated by embodimentsof the invention. The programming and data structures may be accessedand executed by the CPU 142 as needed. The storage 146 is provided forlong-term storage of implementation code and data needed duringoperation. Although a specific hardware configuration is shown for dataprocessing system 100, embodiments of the present invention include anyhardware configuration that allows the browsing of documents, regardlessof whether the computer system is a complicated, multi-user computingapparatus, a single-user workstation, or a network appliance that doesnot have non-volatile storage of its own.

FIG. 2 a is a simplified flow chart of a browser process 200 that occursas a user operates the browser. The process starts (step 202) bylaunching the browser program (FIG. 1, reference numeral 140). Duringoperation, the user initiates various actions, or the browser callsactions, or the browser program or external programs (e.g., serverprogram(s)) (step 204) may provide actions. For purposes ofillustration, such actions will be called “events.” For example, anevent might be to render a page downloaded from a server or stored inthe memory of the client. The browser then determines (step 206) if theevent is to render a page. If so, the browser proceeds to a pagerenderer process at step 208. If the event is something other than torender a page, the browser continues in its execution and handles theevent (step 210) before returning to the get the next event.

FIG. 2 b is a simplified representation of a page renderer file 220 thatis used in a page renderer process. The page renderer file is stored asa data file, for example data file 141 shown in FIG. 1. The page renderfile includes a network address 222 for an electronic document and atype 224. For purposes of discussion, the electronic document will bereferred to as a “page.” The type represents a type of previous userinteraction with the electronic document that invokes the page rendererprocess to present the document on a display according to user habits ofinteracting with the document.

FIG. 3 is a simplified flow chart of a computer program process 300 tostore user interaction habits with a page. The process starts (step 302)when a user interacts with a currently displayed page. The user caninteract with pages in a variety of fashions, such as to scroll the pagevertically or horizontally, to scroll through a table in the page, toenter data into a data entry field on the page, or to select a link onthe page, among other actions. The process gets the user interaction(step 304) and the network address, e.g., URL, associated with the pagebeing displayed (step 306). Getting the URL provides correlationinformation for entry into the page renderer file.

The process 300 then determines which type of user interaction hasoccurred. For purposes of illustration, the first determination (step308) is whether the user is interacting with a table. If the answer isYES, then the process gets the table name, table row, and table column(step 310). With the information received from step 310, the processthen adds or updates data in the table renderer file (step 312). Thetable renderer file may contain entries relating to the URL, the tablename, the table row, the table column, and a count indicating useractivity or user habits on the page, for example. After updating oradding data in the table renderer file (step 312), the process 300returns to get another user interaction (step 304), if any.

If the user has not yet interacted with the page, the process adds anentry to the table renderer file if the user interaction is a type theprocess records for page rendering purposes. Updating occurs if thereare already entries in the table renderer file prior to the present userinteraction. Incrementing a count associated with each page and type ofuser interaction is one way the table renderer file is updated. Thus,the count represents how many times the user has interacted with alocation on a displayed page over a period of time, i.e., the user'sinteraction habits. The count field might fill up eventually, or mightrepresent stale user habit data. Thus, the count field may haveadditional attributes, such as when the user interaction occurred.Another program, running in the background, for example, could keep thecount representative of current user habits by degrading the count overtime.

If, at step 308, the user interaction is not with a table, then theprocess 300 determines if the user is interacting with a link (step314). If the user interaction is with a link, then the process gets thelink taken (step 316) and adds to or updates the link file (step 318)with entries for the network address, the link taken, and an associatedcount for that link on that page. After adding to or updating the datain the link renderer file, the process returns to the get another userinteraction (step 304), if any.

If the user interaction was not to take a link from the displayed page,then the process 300 proceeds to determine if the user interaction wasto enter data (step 320). If the user entered data, then the processgets page field information, such as the HTML element name, where theuser entered data (step 322) and adds to or updates data in a dataentered renderer file (step 324). The data entered renderer file maycontain, for example, the network address, page element name associatedwith the data entry field, and a count. After adding or updating thedata in the data entered renderer file, the process 300 returns to getanother user interaction (step 304), if any.

If the user interaction was not to enter data, then the process 300could proceed to further decision nodes with similar branchingoperations for other types of user interaction(s) 321. For example, auser might simply scroll down or across a page, and the process mightrecord how many rows or columns are scrolled. After the types of entrieshave been evaluated, the process returns to get the next userinteraction (step 304), if any.

FIG. 4 a is a simplified flow chart of a page renderer process 400according to an embodiment of the present invention. This page rendererprocess alters a page display according to user habits. Referringbriefly again to FIG. 2 a, step 206, if the browser encounters an eventthat invokes page rendering, the page renderer process 400 is started(step 402). The page renderer process gets the network address (step404), such as a URL, of the page to be rendered and evaluates whetherthere are any entries in the page renderer file (step 406). If there areno entries in the page renderer file, the page is formatted (step 408)and rendered (step 410), after which the page renderer process is done(step 412), and returns to the main browser program (step 414).

There would not be an entry in the page renderer file, for example, ifthe user had not previously visited the page, or if he had previouslyvisited the page but had not further interacted with the page, or if hehad previously interacted with the page, but not in a way that wouldcreate an entry in the page renderer file for that page. If there is anentry for that page in the page renderer file, the page renderer process400 proceeds to determine the type of entry. In a particular embodiment,the page renderer file has an entry (i.e., key or TRUE flag) if any oneof a specific type of user interaction has previously occurred with thatpage. One of skill in the art will recognize that the order shown isexemplary only, and other orders of decisions and related actions couldbe taken. Additionally, other types of entries (user interactions) couldbe made, which would have additional associated process flows.

Referring again briefly to FIG. 1, the data files 41 a, 41 b, 41 c,store page renderer information relating to user habits. The sum of theindividual data files are collectively referred to as the “page rendererfile” 141. If an entry is present in any of the data files that make upthe page renderer file, then the page renderer process proceeds to step416, which evaluates whether there is an entry in the table rendererfile (e.g., reference numeral 141 a in FIG. 1). If there is an entry inthe table renderer file, then the page renderer process 400 proceeds toa table renderer process (step 418). After the table renderer process iscomplete or if there is no entry in the table renderer file, the pagerenderer process 400 proceeds to the next step 420.

At step 420, the page renderer process 400 evaluates whether there is anentry in a link renderer file (e.g., reference numeral 141 b in FIG. 1).If there is an entry in the link renderer file, then the page rendererprocess proceeds to the link renderer process (step 422). After the linkrenderer process is complete or if there is no entry in the linkrenderer file, the page renderer process 400 proceeds to the next step424.

At step 424, the page renderer process 400 evaluates whether there is anentry in a data entered file (e.g., reference numeral 141 c in FIG. 1).If there is an entry in the data entered renderer file, then the pagerenderer process 400 proceeds to a table entered renderer process (step426). After the data entered renderer process is complete, the pagerenderer process formats the page (step 428) and renders the page (step430).

The steps of formatting and rendering the page may alter the page, suchas by placing a particular line or lines of the document at the top ofthe page, may re-arrange elements of the page, such as lines of a tabledisplayed on the page, may alter the page in a combination of ways, orotherwise put the page to the display according to the page rendererprocess 400. After formatting and rendering the page (steps 428 and430), the page renderer process is done (step 412) and returns to themain browser program (step 414).

If there are entries in more than one renderer file, the process can bestructured so that the last-evaluated entry is what determines pagerendering. In other words, if there is a link taken entry and a dataentered entry in the respective data files, the page is rendered to showthe data entry field at the top of the displayed page because it is thelast type of user interaction evaluated.

FIG. 4 b is a simplified flow chart of a page renderer process 450according to another embodiment of the present invention. This pagerenderer process positions a page on a display according to user habits.Referring briefly again to FIG. 2 a, step 206, if the browser encountersan event that invokes page rendering, the page renderer process 450starts (step 402′). The page renderer process 450 gets the networkaddress (step 404′), such as a URL, of the page to be rendered andevaluates whether there is an entry in the page renderer file (step406′), which would indicate a user had previously interacted with thatpage in a particular fashion. If there is no entry, the page isformatted (step 408′) and rendered (step 410′) to the display. The pagerenderer process is then done (step 412′) and the page renderer process450 returns to the main browser program (step 414′).

If there is an entry in the page renderer file, then the page rendererprocess continues to a page positioning step 452. Those skilled in theart will appreciate that the decision node 406′ of FIGS. 4 b and 406 ofFIG. 4 a could be combined, with an additional branch being added to thedecision node depending on the type of page rendering desired accordingto the user interaction type. Similarly, the processes might sharecommon steps, such as standard formatting 408, 408′ and rendering 410,410′, for example.

The page positioning step 452 recalls user-habit page positioning datawhich could be stored in the page renderer file or another datastructure, such as a page positioning data file. For example, if theuser, after loading the page, scrolls the page to view a particularregion of the page, a page positioning data file stores a page elementor elements associated with the viewed page.

The region of the page that the user views typically depends on thedisplay size and page size. An entry in the page renderer file counts,for example, how many times the user has scrolled to a particularposition (generally indicated by the top displayed line) on a particularpage, which would provide a user interaction field in the entry for thepage renderer file. Thus, different counts are associated with the timesthe user has scrolled to different lines of the page. The userinteraction position on the electronic document is determined by thenumber of lines scrolled or by HTML elements, for example. Such dataprovides user interaction field data to locate a position of anelectronic document with which the user has interacted.

The page positioning step 452 selects the entry in the page rendererfile with the highest count, and provides page positioning informationfor formatting (step 454) and rendering (step 456) the page. The pagepositioning information includes information such as a number or linesto be scrolled from an initial position, HTML elements associated with aline or lines of the page (such as line breaks), or similar informationthat directs the process to re-position the displayed page so that theuser views the line he has most often scrolled to.

The operation of the process shown in FIG. 4 b is different from theoperation of the process shown in FIG. 4 a in that the displayed page isnot re-arranged in the process of 4 b, but merely positioned so that themost interacted with portion of the page is shown at or near the top ofthe display, thus reducing or eliminating the need to scroll to thatlocation on the page. It is specifically understood that the processesillustrated in FIGS. 4 a and 4 b could be combined. For example, theprocess 400 shown in FIG. 4 a can re-arrange a table, and the process450 shown in FIG. 4 b can place the re-arranged table at the top of thedisplayed page.

User interaction with a displayed page may change the page according toconventional browser operation, such as when the user scrolls the pageor enters data. The present invention, in comparison, stores datarelating to user interaction habits and renders a page according tothose habits the next time the user visits that page. In other words,while the user is interacting with a displayed page, the presentinvention is gathering statistics.

FIG. 5 a is a simplified flow chart of a table renderer process 500illustrating one embodiment of step 418 of FIG. 4 a. The table rendererprocess 500 orders the data in the table renderer file by the countfield (“count”) (step 502). The count identifies the row of the tablethe user has interacted with the most. For each entry in the tablerenderer file (step 504), the table renderer process gets the entry(i.e., the stored prior user interaction and associated URL) (step 506).The table renderer process 500 evaluates (step 508) whether therequested page still contains (would display) the table row that isstored in the table renderer file. If the row does not still exist inthe table, then the table renderer process returns to get the next entryin the table renderer file and does not change how the page will bedisplayed. If the data row still exists in the table, the table rendererprocess removes the data row from its current table position (step 510)and moves the table row to the top of the table (step 512),additionally, the table row can be positioned at the top of therequested page. After processing the last entry in the table renderfile, the process 500 is exited at step 514.

In a particular embodiment, the table renderer process 500 arranges theentries in the table renderer file so that the lowest count is at the“top” of the file list (i.e., the first-evaluated entry) and the highestcount is at the bottom of the list. In this fashion, as the tablerenderer process evaluates the entries in the table renderer file, theentry with the highest count is evaluated last, thus displaying thetable row with the highest count at the top of the table. Prior entrieswould be temporarily positioned at the top of the table, but theultimate top row of the table would reflect the highest count.

FIG. 5 b is a simplified representation of a data structure of a tablerenderer file entry 520. The data structure includes a network address522, a table name 524, a row 526 of the table, a column 528 of thetable, and a count 530. The row and column entries provide userinteraction fields to associate a position of the electronic documentwith the user interaction. The table renderer file could include otherfields, such a time field representing how long a user stays on a row ofthe table.

FIGS. 6 a-6 c are simplified representations of tables displayed on auser's display illustrating operation of an embodiment of the presentinvention. FIG. 6 a is a simplified example of a table that might bedisplayed on an HTML page. All entries in the table could be selectableto link the table entry with the stock name, chart of stock price, andrecent news, for example. The entries in the table are one type of pageelement, as are links, data entry fields, and line breaks, among others.A page is typically made up of several elements that the user caninteract with in various ways. The user might enter data into a field,take a link, or scroll to a particular position on the page, theposition being defined according to page elements such as a line number.

For purposes of discussion, it is assumed that the display could notshow the entire table, but rather that the display can show only fourlines of the table. However, the present invention also applies tosituations where the entire table can be shown on a display. Forexample, even though the display can show the entire table, it may bedesirable to have the highest-count row displayed at the top of thetable, or to have a requested page rendered so that the display showsthe most-requested line of the page at the top of the display. It isfurther assumed that the user is interested in linking to informationrelating to HWP and INTC, and visits these links frequently by scrollingto them and selecting the links, and that the user never interacts withthe row relating to JMAR. With conventional browsers, the user wouldtypically scroll down the page to find the table, at which point onlythe first four lines would be displayed (i.e., IBM, JMAR, SUNW, andVCAI). The user would typically then have to continue scrolling if hewanted to view the row containing HWP, for example.

FIG. 6 b shows the lines that would be on the client's display when theuser subsequently requests the page containing the table. A browseraccording to an embodiment of the present invention renders the page todisplay the previously visited information in a selected arrangement.First, the browser displays the page at a point showing the table.Second, the browser re-arranges the table to display the rows havinginformation on HWP and INTC at the top of the table. FIG. 6 c shows thelines that the browser would not display, including JMAR, which hasdropped to the bottom row of the table. The user could scroll the pagedown to view these rows of the table, if desired. Similarly, theinvention can re-arrange other items on a page, such as links, images,or headlines. Furthermore, the browser could track the overall timespent by the user at various points of a URL and initially position theclient display to show the part of the URL that the user has spent themost time on. Such time data could decide row or other entry priority ifthe counts for two rows are the same, for example.

FIG. 7 a is a simplified flow chart of a link renderer process 700showing one embodiment of step 422 of FIG. 4 a. The page rendererprocess 400 of FIG. 4 a invokes the link renderer process 700 when theuser selects a page and the link renderer file has an entry associatedwith that page. The link renderer process 700 evaluates each entry inthe link renderer file (step 702) by getting an entry (step 704) andevaluating if the page still displays the link associated with the entry(step 706).

If the link does not still exist on the page, then the link rendererprocess 700 returns to get the next entry in the link renderer file, anddoes not re-arrange the display field (i.e., portion of the displayedpage) or re-position the page. If the link still exists on the page, thelink renderer process removes the link from its current position (step708) and moves the link to the top of the displayed page (step 710).After processing the last entry in the link render file, the process 700exits at step 712.

FIG. 7 b is a simplified representation of a data structure of alink-taken file entry 720. The entry includes a network address 722associated with the page on which the link occurred when the userinteracted with the link, the link taken by the user 724, and a count726.

FIG. 8 a is simplified flow chart of a data entered renderer process 800showing one embodiment of step 426 of FIG. 4 a. The page rendererprocess 400 of FIG. 4 a invokes the data entered renderer process 800when a user selects a page and the data entered renderer file has anentry associated with that page. The data entered renderer process 800evaluates each entry (step 802) in the data entered renderer file bygetting an entry (step 804) and evaluating if a data entry field, suchas an HTML element, associated with the entry still appears on thecurrent (requested) page (step 806).

If the data entry field does not still exist on the page, then the dataentered renderer process 800 returns to get the next entry in the dataentered renderer file, and does not re-arrange the displayed page. Ifthe data entry field still exists on the page, then the data enteredrenderer process removes the data entry field from its position on theformatted page (step 808) and moves the data entry field to the top ofthe page (step 810). After processing the last entry in the data enteredfile, the process 800 exits at step 812.

FIG. 8 b is a simplified representation of a data structure of adata-entered file entry 820. The data-entered file entry includes anetwork address 822, a data entry field identifier, such as an HTMLelement name, 824 and a count 826.

While the present invention has been described with respect to thepreferred and alternative embodiments, it will be understood by thoseskilled in the art that various changes in detail may be made thereinwithout departing from the spirit, scope, and teaching of the invention.For example, in a further embodiment, each of the renderer processescould include a device query step to determine the number of linesavailable for display and further modify the rendering of the displayedpage. In yet a further embodiment, the display resolution could bestored for use in the page rendering process as part of the as-providedclient. Accordingly, the herein disclosed invention is to be limitedonly as specified in the following claims.

1. A configurable client computer for use in a client-server computersystem, the client computer comprising: a display; and a browser capableof rendering electronic documents to the display, the browser beingcapable of accessing user habit data in association with electronicdocument address data, and a renderer capable of rendering a selectedelectronic document to the display according to the user habit data. 2.The configurable client computer of claim 1, further comprising a pagerenderer file configured to store the user habit data.
 3. Theconfigurable client computer of claim 1, wherein the display is capableof displaying, at most, a number of lines less than a number of lines ofthe selected electronic document.
 4. The configurable client computer ofclaim 1, wherein the renderer renders the selected electronic documentto the display by repositioning the selected electronic document todisplay a page location at a top portion of the display.
 5. Theconfigurable client computer of claim 1, wherein the renderer rendersthe selected electronic document to the display by rearranging elementsof the selected electronic document to display a page location at a topportion of the display.